Skip to content

Expose --num-workers and --native-parser#21387

Merged
ilevkivskyi merged 3 commits intopython:masterfrom
ilevkivskyi:expose-paralleland-parser
May 1, 2026
Merged

Expose --num-workers and --native-parser#21387
ilevkivskyi merged 3 commits intopython:masterfrom
ilevkivskyi:expose-paralleland-parser

Conversation

@ilevkivskyi
Copy link
Copy Markdown
Member

Three things here:

  • Add the docs for --num-workers and --native-parser
  • Remove argparse.SUPPRESS from them
  • Add couple checks for num_workers

cc @JukkaL

@github-actions

This comment has been minimized.

Copy link
Copy Markdown
Collaborator

@JukkaL JukkaL left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, left a few minor comments.

Comment thread docs/source/command_line.rst Outdated
Parallel type-checking
**********************

By default, mypy checks all modules in the same Python process, this can be slow
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Grammar nit: '... process. This can be slow ...'

Comment thread docs/source/command_line.rst Outdated

* Specifying a number of workers that is larger than the number of *physical*
CPU cores is not beneficial, since mypy is usually CPU bound. Best way to
tune the number of workers on a given machine is to start from 2-3 workers
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe suggest starting from 4 workers, since almost all CPUs have at least 4 cores these day (except for some CI jobs perhaps)?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reasons I think 2-3 is a good start:

  • We need to save one core for the coordinator process.
  • GitHub action runners are usually really basic.

Anyway, I can probably say "3-4" instead of "2-3".

Use ``NUMBER`` parallel worker processes (in addition to the coordinator
process) to perform type-checking. Specifying ``--num-workers 0`` (default)
disables parallel checking. Automatic detection of the optimal number
of workers is not supported yet.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we limit the number of workers based on the number of actual cores, e.g. if only 4 cores are available and 16 workers are requested, are we still using 16 workers?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No we do not. Actually during parallel parsing we even do the opposite: if the auto-detected number of cores is smaller than --num-workers, then we use --num-workers instead.

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 1, 2026

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

@ilevkivskyi ilevkivskyi merged commit 7760563 into python:master May 1, 2026
25 checks passed
@ilevkivskyi ilevkivskyi deleted the expose-paralleland-parser branch May 1, 2026 11:14
JukkaL pushed a commit that referenced this pull request May 1, 2026
Three things here:
* Add the docs for `--num-workers` and `--native-parser`
* Remove `argparse.SUPPRESS` from them
* Add couple checks for `num_workers`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants